Constructing ground truth when classifying data

ABSTRACT

The present disclosure relates to evaluating whether two data records reflect the same entity using a classifier in the absence of ground truth. Without ground truth, it is difficult to determine the precision or recall of a classifier. The present disclosure generates a list comprising a series of unique feature signatures and a set of sample record pairs for each unique feature signature. In some embodiments, users may provide labels for the set of sample record pairs for each unique feature signature.

CROSS REFERENCE TO RELATED MATTERS

This application is a continuation of U.S. patent application Ser. No.16/678,841, filed Nov. 8, 2019, which is a continuation of U.S. patentapplication Ser. No. 15/729,960, filed Oct. 11, 2017, both of which areincorporated by reference in their entirety.

BACKGROUND

In the field of computing, there may be large amounts of data that needto be classified into categories. Classifiers or similar computingmodules operate by searching for commonalities in data structures orattributes within an input dataset. Classifiers are configured accordingto classification rules. They may also be trained using known inputdata. For example, a classifier may be designed to classify the genre ofa piece of music by analyzing an audio file. To train this classifier, auser inputs audio files of a known genre such as “jazz” along with anindication that the input audio files are “jazz.” To this end, theclassifier can learn how to classify “jazz” by analyzing an audio filethat is known to be “jazz.” The knowledge that a particular audio fileshould be classified as “jazz” is called “ground truth.”

Ground truth allows for classifiers to be trained to ensure theclassifier is reliable in terms of precision and recall. The presentdisclosure describes classifying data when there is no ground truth.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood withreference to the attached drawings. The components in the drawings arenot necessarily drawn to scale, with emphasis instead being placed uponclearly illustrating the principles of the disclosure. Moreover, in thedrawings, like reference numerals designate corresponding partsthroughout the several views.

FIG. 1 is a drawing of a computing system 100 according to variousembodiments of the present disclosure.

FIG. 2 is an example of a database table 112 of FIG. 1 according tovarious embodiments of the present disclosure.

FIG. 3 is an is an example of a filtered database table 112 of FIG. 2according to various embodiments of the present disclosure.

FIG. 4 is an example of operations performed by the software applicationexecuting within the computing system 100 of FIG. 1 according to variousembodiments of the present disclosure.

FIG. 5 is an example of data generated by performing pairwisecomparisons in the computing system 100 of FIG. 1 according to variousembodiments of the present disclosure.

FIG. 6 is an example of output data generated in the computing system100 of FIG. 1 according to various embodiments of the presentdisclosure.

FIG. 7 is an example of user data used in the computing system 100 ofFIG. 1 according to various embodiments of the present disclosure.

FIG. 8 is a flowchart illustrating an example of the functionality ofthe software application executed in a computing system 100 of FIG. 1according to various embodiments of the present disclosure.

FIG. 9 is a schematic block diagram that provides one exampleillustration of a computing system 100 of FIG. 1 according to variousembodiments of the present disclosure.

DETAILED DESCRIPTION

Various embodiments of the present disclosure relate to classifying datain the absence of ground truth. Ground truth refers to the knowledgethat a piece of data accurately represents a real-world entity such as aphysical person, place, or thing. In the computing world a real-worldentity can be represented as a record containing information about thereal-world entity, such as attributes about the real-world entity. Forexample, there could be an individual who is “John Doe” and who is anentity that is part of the real-world. In the computing world, a recordmay be stored to represent this real-world entity. In addition, therecould be three different records that include the names “John Doe,”“Jonathan Doe,” and “J. Doe,” respectively that all represent the sameperson. Or, these records might represent different individuals named“John Doe.” Therefore, there is a link between a particular record andthe real-world entity (e.g., the person, John Doe) that it purports torepresent. Ground truth refers to knowledge as to whether that link isaccurate or not.

The present disclosure describes a software application that generatesdata to validate the performance of a classifier or to train aclassifier in the absence of ground truth. The software applicationperforms a number of comparisons, identifies a signature for eachcomparison, generates output data that includes a limited,representative sample of signatures, and validates a classifier usingthe output data and user data. The following figures provide a detailedexplanation of various embodiments of the present disclosure.

FIG. 1 shows a computing system 100 according to various embodiments.The computing system 100 is made up of a combination of hardware andsoftware. The computing system 100 includes a database 103, a softwareapplication 106, and a classifier 109. The computing system may beconnected to networks such as the Internet, intranets, extranets, widearea networks (WANs), local area networks (LANs), wired networks,wireless networks, or other suitable networks, etc., or any combinationof two or more such networks.

The computing system 100 may comprise, for example, a server computer orany other system providing computing capability. Alternatively, thecomputing system 100 may employ a plurality of computing devices thatmay be arranged, for example, in one or more server banks or computerbanks or other arrangements. Such computing devices may be located in asingle installation or may be distributed among many differentgeographical locations. For example, the computing system 100 mayinclude a plurality of computing devices that together may comprise ahosted computing resource, a grid computing resource and/or any otherdistributed computing arrangement. In some cases, the computing system100 may correspond to an elastic computing resource where the allottedcapacity of processing, network, storage, or other computing-relatedresources may vary over time. The computing system may implement one ormore virtual machines that use the resources of the computing system100.

Various applications and/or other functionality may be executed in thecomputing system 100 according to various embodiments. Also, variousdata is stored in the database 103 or other memory that is accessible tothe computing system 100. The database 103 may represent one or moredatabases 103.

The data stored in the database 103 includes one or more database tables112. A database table 112 includes several records, where each recordhas one or more corresponding fields. A database table 112 may be linkedor otherwise associated with one or more relational tables 115. Thecomponents executed on the computing system 100 include a softwareapplication 106 and a classifier 109, which may access the contents ofthe database 103. When stored in a relational database, a database table112 may be linked to one or more relational tables 115. For example, ifan airline company maintained a database table 112 that stored customerrecords, there may be a relational table 115 storing the flight historyfor each customer. The contents of the relational table 115 link to acorresponding record.

Next, a general description of the operation of the various componentsof the computing system 100 is provided. Various businesses or otherentities utilize the computing system 100 to store information in adatabase. For example, businesses may want to store records reflectingcustomers, products, transactions, events, items, or any other piece ofinformation relevant to the business. Records are collected over timeand stored in one or more database tables 112. For example, when abusiness gets a new customer, a software program may create a recordreflecting the new customer. This record may include the customer'sname, address, contact information, or any other information thatidentifies the customer. Such information is stored as fields within adatabase table 112.

In practice, a single record is sufficient to represent a customer.However, it is possible that duplicate or redundant records areinadvertently or unintentionally created and/or exist within thedatabase 103. For example, a customer may register with a business viaan online portal which creates a customer record for that customer.Later, the same customer may inadvertently register again with theonline portal, thereby creating a redundant customer record. As anotherexample, two businesses maintaining their own customer records may mergesuch that the same customer may exist in two different database tables112. The resulting merged database table 112 could have redundantrecords.

Because multiple records may represent the same real-world entity, it isdesirable to group related records together. A classifier 109 may beused to determine whether two records should be classified as a matchbased on the degree of common features between the two records. Theclassifier 109 may be a binary classifier that determines whether a pairof records reflect the same entity or whether they do not reflect thesame entity. A record pair (i.e., two records being compared) areconsidered to be a related pair if they reflect the same entity or anunrelated pair if they do not. A classifier 109 may make decisions basedon a threshold level of similarity. For example, based on the degreethat two records share similar field values, the classifier 109 couldoutput a binary result (e.g., yes or no) that the two records aresimilar enough to be deemed a related pair.

When ground truth is known, it is easy to verify whether the classifier109 is accurate. For example, a classifier 109 may be configured todetermine whether a digital image represents a picture of a particularindividual. Here, a picture is inputted into the classifier 109 and ayes-no result is provided. Because a user knows the truth by examiningthe picture, the performance of the classifier 109 may be evaluated. Thepresent disclosure addresses the issue of classifying data when groundtruth is not known or practically unknowable. This case may arise whenclassifying data where a user does not know the truth or cannot readilyascertain the truth. For example, a user may compare two records todetermine whether they represent the same entity without knowing how toverify the result. This also becomes problematic when dealing with alarge quantity of records and classifications to make. Here, it may beimpractical to classify large sets of data.

According to various embodiments, the software application 106 of thepresent disclosure operates by generating signatures (discussed infurther detail below) by comparing pairs of records within a sample setof pairs, generating output data. Different combination of record pairsfrom a set of records form the sample set of pairs. For example, if aset of records includes records A, B, and C, then the sample set ofpairs may be A-B, A-C, and C-B. The output data includes a list ofunique signatures, as well as corresponding record pairs limited to apredetermined sample size for each signature. Users may then provideinput by labelling the output data. This may involve indicating aclassification for the sampled record pairs. For example, a user mayprovide a label indicating whether each record pair in the output datais a match or no-match. Labeled data is used to establish ground truth.Based on this user data, the software application 106 may quantify theperformance of the classifier 109 by calculating a precision value orrecall value. Furthermore, the software application may weight eachsignature according to its frequency of occurrence in a sample set ofpairs when quantifying the precision or recall of the classifier 109. Inaddition, the user input may be used to train the classifier 109 toimprove its performance.

FIG. 2 shows an example of a database table 112 of FIG. 1 according tovarious embodiments of the present disclosure. A database table includesone or more records 201, where each record has one or more fields 213. Arecord 201 may or may not have all its fields 213 populated. Each record201 is intended to be dedicated to a real-world entity. For example,“record 0001” is intended to be the record representing an individualnamed “Jane Johnson.” “Record 2” is intended to be the record for “MikeSmith” and so on. The example in FIG. 2 includes 99,999 records and fivefields, although any number of records 201 and fields 213 may be used ina manner consistent with the present disclosure.

In various embodiments, the fields 213 are semantic fields such thatthey are normalized across a several database tables 112. For example,one database table 112 may have its F2 field originally called“last_name” while a different database table 112 may have its F2 fieldoriginally called “surname.” By using semantic fields, various databasetables 112 conform to a universal format of identifying its fields. Thisway, the software application 106 (FIG. 1) understands that the“last_name” field of one database table 112 maps to the “surname” fieldof a different database table 112. The database 103 (FIG. 1) may store alookup table that maps original fields to semantic fields in order tonormalize the fields across multiple database tables 112.

As discussed in further detail below, two records are compared todetermine if the records should be classified as a related pair orunrelated pair. To compare two records, field values among the pair ofrecords are compared. For example, in one embodiment, the value of F1 offirst record is compared to the value of F1 of a second record, then thevalue of F2 of the first record is compared to the value of F2 of thesecond record, and so on. The comparison of two values yields a featurewith respect to the record pair. A feature is a programmed calculationtaking as inputs M records and/or other data such as external metadataand returning a numeric value as output. The variable M=2 in the case ofhandling a record pair. That numeric output may be, for example, a realvalue bounded between 0 and 1, or a binary value with two distinctoutputs, with 0 being considered “false” and 1 being considered “true.”A feature score is the specific output value generated by a feature fora given set of records or record pair.

For example, comparing F1 of record 00004 (“Joseph”) to F1 of record99999 (“Joe”) may yield a “first name feature” having a feature score of0.88 on a scale of 0 to 1, where 0 means no-match and 1 means a perfectmatch. In other embodiments, the first name feature with respect torecord values “Joe” and “Joseph” may be a binary value of “true/T”meaning there is a match. For purposes of illustration the presentdisclosure uses binary values to represent features, however, it shouldbe appreciated that a non-binary value may be used as a feature.

In other embodiments, a subset of field values may be compared to acorresponding subset of field values. For example, the combination offield values F1 and F2 of a first record may be compared to thecombination of field values F1 and F2 of a second record. The comparisonmay involve concatenating the values of F1 and F2 as well asconcatenating the transposed values of F1 and F2. This way F1 and F2 ofa first record is compared to F1 and F2 of a second record, as well asF2 and F1 of the second record. The resulting feature with respect to aset of fields may account for whether there is a match between fields'values when they are transposed. As an example, “John Doe” compared to“John Doe” may yield a value of ‘true’ for the “Names Matched” featurewhile “John Doe” compared to “Doe John” may yield a value of ‘true’ forthe “Transposed Names Matched” feature.

FIG. 3 is an example of a filtered database table 112 of FIG. 2according to various embodiments of the present disclosure. The records201 (FIG. 2) in the database table 112 may be organized into a set ofrecord pairs 307 (also referred to a set of unfiltered records pairs)having different combinations of records 201. The number of recordcombinations may be large. FIG. 3 shows how the 99,999 records of FIG. 2may be filtered down to a much smaller set of related record pairs thatare likely to be classified as record pairs. This is done by performinga plurality of blocking functions 310. The result is a filtered set ofpairs 315 that include pairs that have a relatively higher chance ofbeing related pairs. The blocking functions reduces the number of pairsthat need to be processed, thereby requiring fewer processing resourcesfor analyzing related pairs. Assuming there are 99,999 records, thenumber of pairs to consider, without applying a blocking function is4,999,850,001, which is calculated according to the formula:

n*(n−1)/2

where n is the number of records.

The purpose of a blocking function 310 is to coarsely select recordpairs that share some related information and which could represent thesame real-world entity. For example, a blocking function 310 may operateto determine if two records 201 are sufficiently similar enough wherethey might be classified as a related record pair. This may involvedetermining which field values are similar or are the same. One exampleof a blocking function 310 is to compare a “social security number(SSN)” field. Two records 201 having the same SSN field values likelymeans that the two records form a related pair. Another example of ablocking function 310 is to compare the first three characters of afirst name field and first three characters of a last name field betweentwo records. By performing a plurality of blocking operations 310, arelatively large set of records is reduced in size to include anover-inclusive set of records that are likely to be a part of a relatedpair.

Referring next to FIG. 4, which is an example of operations performed bythe software application 106 executing within the computing system 100of FIG. 1 according to various embodiments of the present disclosure.The software application 106 is configured to identify pairs within aset of records. The set of records may be filtered down by way of ablocking operation 310 (FIG. 3) to yield a filtered set of pairs 315.

The software application 106 selects a record pair made up of a firstrecord 403 and a second record 406 among a set of records to perform apairwise comparison 409. Once a record pair is selected, the softwareapplication performs a pairwise comparison 409. This may involvecomparing the field values between the two records 403 and 406 todetermine a feature for a particular field or set of fields. Thepairwise comparison 409 generates a feature signature 412 which may bemade up of various features of the fields' values being compared.

The feature signature 412 reflects how two records are similar ordissimilar based on the extent the field values are similar. In otherwords, the feature signature 412 corresponds to a series of featuresbetween a pair of records being compared. Two different record pairs mayhave the same feature signature 412 even though they represent differententities. In this case, it is inferred that the records in the firstpair are similar in the same way they related to one entity as recordsin the second pair relate to a different entity. For example, given thetrivial set of binary features “Fuzzy Last Name match” and “Fuzzy FirstName match”, the record pair {“Stephen Meyles”, “Steve Myles”} willgenerate a feature signature of [1 1], where “1” refers to a binaryvalue indicating a match. In addition, a record pair of {“Derek Slager”,“Derke Slagr”} will also generate a feature signature 412 of [1 1]. Thisdoes not necessarily mean that the first pair of records are related tothe same real-world identity as the second pair of records. Instead itsuggests that the records have the same data variations (fuzzy matchesof first and last name). Records with the same data variations may havethe same signature. This is discussed in further detail with respect toFIG. 5.

After generating the feature signature 412, the software application 106uses a classifier 109 (FIG. 1) to perform a classification process 415on the feature signature 412. The classification process calculates aclassification score that correlates to the strength that a particularfeature signature indicates a match. For example, a score of 0 meansno-match while a score of 1 means a perfect match. After calculating aclassification score, the classifier 109 compares the classificationsscore to a predetermined threshold score to yield a decision 423 thatclassifies the feature signature 412. According to various embodiments,the decision 423 is a binary value that indicates if the featuresignature 412 reflects a match or no match. A pair that is classified asa match is deemed a related pair while a pair that is classified as ano-match is deemed an unrelated pair. This process above may processpairs in batches until all record pairs within a set of pairs isprocessed. Each pairwise comparison 409 is subject to a classificationprocess 415 that generates a respective decision 423.

The software application 106 generates output data 429. The output data429 may include a list of unique feature signatures 412 along withcorresponding record pairs limited to a predetermined sample size foreach unique feature signature 412. Accordingly, the record pairs areselected to represent a diverse set of feature signatures 412. Therecord pairs of the output data 429 may be submitted to a user who thenprovides user data 431 such as labels for record pairs. Output data 429combined with user data 431 may be used to evaluate a classifier 109 andto estimate ground truth for various feature signatures 412. This isdiscussed in more detail with respect to FIG. 7.

When configuring the classifier 109, it may be desirable to validate theclassifier 109. This ensures that the classifier 109 is accuratelyclassifying the feature signature 412 to determine whether two recordsshould b e considered a related pair or unrelated pair. The softwareapplication 106 may perform a validation process 426 by analyzing userdata 431 in the absence of actual ground truth. The software applicationperforms a validation process 426 by analyzing the output data 429 andgenerating a result. The result quantifies the performance of theclassifier 109 by calculating a precision value and/or a recall value.In addition, the user data 431 may include labels for the record pairsrepresented by a diverse group of feature signatures 412. The labeledrecord pairs may be used for classifier training 437.

FIG. 5 provides an example of data generated by performing pairwisecomparisons 409 in the computing system 100 of FIG. 1 according tovarious embodiments of the present disclosure. The software application106 may generate the data shown in FIG. 5 by performing a numberpairwise comparisons 409 (FIG. 4) on a set of record pairs to generatecorresponding feature signatures 412. The data in FIG. 5 identifies afirst record 403 and a second record 406 that are subject to a pairwisecomparison 409. The data also includes a feature signature 412 that isgenerated in response to the pairwise comparison 409 (FIG. 4).

The feature signature 412 may indicate which features between two ormore records are the same. FIG. 5 provides an example of comparingsingle fields, however, a feature may reflect a comparison between twoor more fields. The example of FIG. 5 uses a “T” for true to indicatethat the field values between two records is the same and uses an “F”for false if the field values between two records are not the same. Asshown in FIG. 5, a pairwise comparison 409 between record 00004 andrecord 99999 yields a feature signature of “TTFTF.” In this example,when comparing a field value to a null value, the resulting feature is“F.” The example of FIG. 5 shows how records having five fields arebeing compared. When records have more fields, then a larger variety offeature signatures 412 can exist.

The feature signature 412 of FIG. 5 is based on the following set offeatures: “fuzzy_first_name_match”, “fuzzy_last_name_match”,“email_match,” “zip_code_match”, and “last_4_SNN_digits_match.” Itshould be appreciated that other features may be used to generate thefeature signature 412 such as “Transposed_names_match,” which comparesconcatenated values of F1 and F2 of one record to concatenated values ofF2 and F1 of a second record. In addition, the feature signature 412 mayinclude a feature such as “first_name_match,” which requires anidentical match rather than a fuzzy match. Another example is a featurebased on the concatenation of the first three characters of a first nameand the first three characters of the last name. Here “Josh Mills”compared to “Joseph Miller” would generate a feature score of “True/1”because both have the same feature of “JOSMIL”, which results from theconcatenation of the first three characters of the first name and thefirst three characters of the last name.

Instead of using binary feature values, feature values may be non-binarysuch as “exact-match,” “approximate-match,” “non-conflicting,” and“unlike.” Here, “exact-match” refers to the case where field valuesbetween two records are identical and “approximate-match” refers tofield values that are sufficiently similar such as “Jon” and “Jonathan.”A “non-conflicting” feature refers to a case where a field value iscompared against a null field value. And “unlike” refers to values thatare sufficiently dissimilar such as “Steve” and “Jon.” More detailed orcomplex feature values may result in a larger variety of featuresignatures. Thus, while the feature signature 412 of FIG. 5 usesfeatures having binary values, other embodiments may use non-binaryvalues.

The classifier 109 (FIG. 1) computes a classification score on a featuresignature 412 and then compares that classification score to a thresholdscore to determine whether the feature signature 412 corresponds to apair of records that are related or unrelated. A feature score of“TTTTT” would yield a perfect score and therefore classify a record pairhaving that feature signature as a related pair.

Based on how a classifier 109 is configured, the classifier 109 maydetermine that a feature signature “TTFTF” should be classified as amatch. Accordingly, record 00004 and record 99999 would be considered arelated pair and thus, indicative of the same real-word entity. Usingthe example of FIG. 3, the “Joseph Miller” of record 00004 and the “JoeMiller” of record 99999 are considered to represent the same individual,who, in the real world, is a person named “Joe Miller” or “JosephMiller.” In the example of comparing record 00004 to record 99999, a“fuzzy_first_name_match” field” yielded a “True/T” as a result ofcomparing “Joe” to “Joseph.” A “fuzzy_first_name_match” feature relatesto whether the first names are identical or substantially identical byapplying a fuzzy string comparison algorithm. In addition, the“fuzzy_last_name_match” feature yielded a “True/T” because both lastname field values are equal or substantially equal. An “email_match”feature yielded a “False/F” because record 00004 has a null value whilerecord 99999 does not. A “zip_code_match” yielded a “True/T” becauseboth zip codes are identical. And a “last_4_SSN_digits_match” yielded a“False/F” because 99999 has a null value while record 00004 does not. Bycombining these feature scores, the resulting feature signature is“TTFTF.”

When analyzing a relatively large set of records, some featuresignatures 412 may be more common than others. To improve validation ofthe classifier 109, a variety of feature signatures 412 should beevaluated regardless of how commonly they occur. The present disclosuredescribes generating output data 429 (FIG. 4) to assist in evaluatingthe classification process 415 (FIG. 4).

Next, FIG. 6 provides an example of output data 429 generated in thecomputing system 100 of FIG. 1 according to various embodiments of thepresent disclosure. The output data 429 lists the feature signatures 412resulting from performing pairwise comparisons 409 (FIG. 4) on a set ofrecords. The list uniquely identifies feature signatures 412 by avoidingduplicative listings of the feature signatures 412. For a given featuresignatures 412, the output data may identify the frequency of occurrence603 of the given feature signature 412, a percentage of occurrence 606of the given feature signature 412, and a limited set of sampled recordpairs 613 for the given feature signature 412.

The output data 429 indicates how often a particular feature signature412 occurs within a set of records. The output data includes a sampleset of record pairs 613 representing each feature signature 412.According to various embodiments, the output data 429 limits the samplesize to a predetermined size. The example of FIG. 6 uses a predeterminedsize of three so that for each feature signature 412 there are threeidentified sample pairs. The sample set of record pairs 613 may besampled randomly. Alternatively, the sample set of record pairs 613 areidentified according to sequentially processing the set of records. Forexample, when a feature signature 412 is generated as shown in FIG. 4,the software application 106 (FIG. 1) writes the corresponding pair intothe output data 429 for the particular feature signature 412. This willcontinue each time the software application 106 encounters the samefeature signature 412 up until the predetermined sample size is reached.After that, no more record pairs are written as output data 429. Inother embodiments, the software application 106 computes the featuresignatures 412 for the entire set of records and then selects k samplesfor each distinct feature signature, where k is the predetermined samplesize.

The example of FIG. 6 shows that the feature signature 412 of “TTFTF”occurs most frequently relative to other feature signatures 412. Insteadof documenting each record pair for a given feature signature 412, theoutput data 429 limits the sample size to generate the sample set ofrecord pairs 613. Moreover, randomly sampling record pairs from the setof records without limitation will likely yield more record pairs havinga feature signature 412 of “TTFTF” over any other feature signature 412.This makes it more difficult to evaluate the full spectrum of featuresignatures 412.

FIG. 7 provides an example of user data 431 used in the computing system100 of FIG. 1, according to various embodiments of the presentdisclosure. After the software application 106 (FIG. 1) generates outputdata 429 (FIGS. 4 and 6), a user may analyze the sample set of recordpairs 613 within the output data 429 and label it to assist invalidating or training the classifier 109 (FIG. 1). The user data 431applied to a sample set of record pairs 613 forms labeled record pairs717.

The sample set of record pairs 613 may be provided to a user. The usercan analyze one or more of the sampled record pairs 613 for each featuresignature 412 to determine whether the user believes that the sampledrecord pairs 613 reflects a match or not. For each record pair, the userprovides user data 431 such as a corresponding label indicating a matchor no-match.

Once the labeled record pairs 717 are generated, the softwareapplication 106 may either validate the classifier 109 or to train it.To validate the classifier 109, the software application 106 maygenerate predictive values 723 such as “true positive,” “falsepositive,” or “false negative” by analyzing the labeled record pairs717. FIG. 7 shows that all three sampled record pairs 613 associatedwith a feature signature of “TTFTF” were true positives. This impliesthat the classifier 109 (FIG. 1) is likely correct when classifying arecord pair that yields a feature signature of “TTFTF.”

As another example, the user data 431 of FIG. 7 shows that among thethree sampled record pairs 613 for feature signature 412 of “FFTTF,”there are two are false positives and one false negative based onanalyzing the labeled record pairs 717. This implies that the classifier109 (FIG. 1) is likely incorrect when classifying a record pair thatyields a feature signature of “FFTTF” As a match. According to variousembodiments, the predictive values may be used to calculate a precisionvalue or recall value for the classifier 109 using a weight 712 for thefeature signature 412. The weight 712 may be equal or proportional tothe percent that a particular feature signature 412 occurs within asample set.

In addition to validating the classifier 109, the labeled record pairs717 may be used to train the classifier 109. Here the classifier 109 maybe provided with labeled record pairs 717 to configure the classifier109. The labeled record pairs 717 serve as ground truth that has beenoptimized to represent a diverse set of feature signatures where thediverse set of features has been equalized using the predeterminedsample size.

FIG. 8 is a flowchart that provides an example of the operation of thesoftware application 106 according to various embodiments. It isunderstood that the flowchart of FIG. 8 provides merely an example ofthe many different types of functional arrangements that may be employedto implement the operation of the portion of the software application asdescribed herein. As an alternative, the flowchart of FIG. 8 may beviewed as depicting an example of elements of a method implemented inthe computing system 100 (FIG. 1) according to one or more embodiments.

Beginning at 802, the software application 106 accesses one or moredatabase tables 112 (FIG. 1). Here, the software application 106identifies a set of records 201 (FIG. 1) included within a databasetable. While two or more records may occupy separate lines within thedatabase table 112, it is possible that these records represent the samereal-world entity, whether it be the identity of a customer, an object,an event, or any other real-world entity. Two records that sharecommonalities are referred to as record pairs.

At 805, the software application 106 selects record pairs that arelikely to be classified as related pairs. For example, the softwareapplication 106 may perform a series of blocking functions 310 (FIG. 3).The result is a filtered set of record pairs 315 (FIG. 3).

At 808, the software application 106 performs a number of pairwisecomparisons 409 (FIG. 4) on various record pairs in a set of recordpairs. Assuming a blocking operation is performed, the set of recordpairs is a set of filtered record pairs 315 (FIG. 3). At 811, eachpairwise comparison 409 yields a feature signature 412 (FIG. 4). Thefeature signature 412 is a pattern that corresponds to how a firstrecord 403 and a second record 406 are similar. This may involvedetermining which features, derivative of field values, are similar orare the same.

At 813, the software application 106 generates output data 429 (FIG. 4).The output data 429 may include a comprehensive list of the calculatedfeature signatures 412 occurring within a set of record pairs. Moreover,the output data 429 may contain a limited number of sampled record pairs613 (FIG. 6) that represent a particular feature signature 412. Thebenefit of limiting the sample size is to prevent more common featuresignatures 412 from dominating the output data 429.

The output data 429 may be a file that is written to by the softwareapplication 106 as it is generating feature signatures. In this case,the software application 106 continues to write sampled record pairs 613to the output data 429 until a predetermined sample size is reached fora given feature signature 412. This limits the amount of sampled recordpairs 613 per feature signature 412 in the output data 429.

Once generated, the sampled record pairs 613 in the output data 429 maybe transmitted to a user. The software application 106 may communicatewith a client device over a network. For example, a user may use apersonal computer, laptop, mobile device, or other computing device tointerface with the software application 106. This may involve the use ofan online portal. The user may download the sampled record pairs 613onto a client.

At 815, the software application obtains user data 431 (FIGS. 4 and 7),which may include labels. A user may review the sampled record pairs613, evaluate it, and submit user data 431 to the software application106. For example, the user may submit user data 431 via an online portalor online form or any other mechanism to upload data within thecomputing system 100 (FIG. 1). The user input may label the sampledrecord pairs 613 as to whether they represent a match or no-match.

At 818, the software application 106 trains the classifier 109 usinglabeled record pairs 717 (FIG. 7). Here, the classifier 109 is providedwith the sampled record pairs 613 along with user data 431, which mayinclude corresponding labels for the sampled record pairs 613. In thisrespect, the labeled record pairs 717 serve as an optimized set ofground truth for classifier 109 training.

At 821, the software application 106 validates a classifier 109 (FIG. 1)using the user data 431. For example, the software application 106 maycalculate a precision value or recall value for the classifier 109 usingthe user data 431. Moreover, the software application 106 may weighteach feature signature 412 based on prevalence of the feature signature412 within a set of record pairs. This may lead to a more accuratecalculation of the precision value or recall value. For example, in FIG.7, the feature signature 412 of “TTFTF” is the most common featuresignature and therefore, the user data 431 relating to this signaturewill be given the most weight.

FIG. 9 shows a schematic block diagram of the computing system 100according to an embodiment of the present disclosure. The computingsystem 100 includes one or more computing devices 900. Each computingdevice 900 includes at least one processor circuit, for example, havinga processor 903 and memory 906, both of which are coupled to a localinterface 909 or bus. To this end, each computing device 900 maycomprise, for example, at least one server computer or like device. Thelocal interface 909 may comprise, for example, a data bus with anaccompanying address/control bus or other bus structure as can beappreciated.

Stored in the memory 906 are both data and several components that areexecutable by the processor 903. In particular, stored in the memory 906and executable by the processor 903 is the software application 106.Also stored in the memory 906 may be a database 103 and other data suchas, for example, the output data 429 and user data 431. In addition, anoperating system may be stored in the memory 906 and executable by theprocessor 903.

It is understood that there may be other applications that are stored inthe memory 906 and are executable by the processor 903 as can beappreciated. Where any component discussed herein is implemented in theform of software, any one of a number of programming languages may beemployed such as, for example, C, C++, C#, Objective C, Java®,JavaScript®, Perl, PHP, Visual Basic®, Python®, Ruby, Flash®, or otherprogramming languages.

Several software components are stored in the memory 906 and areexecutable by the processor 903. In this respect, the term “executable”means a program file that is in a form that can ultimately be run by theprocessor 903. Examples of executable programs may be, for example, acompiled program that can be translated into machine code in a formatthat can be loaded into a random access portion of the memory 906 andrun by the processor 903, source code that may be expressed in properformat such as object code that is capable of being loaded into a randomaccess portion of the memory 906 and executed by the processor 903, orsource code that may be interpreted by another executable program togenerate instructions in a random access portion of the memory 906 to beexecuted by the processor 903, etc. An executable program may be storedin any portion or component of the memory 906 including, for example,random access memory (RAM), read-only memory (ROM), hard drive,solid-state drive, USB flash drive, memory card, optical disc such ascompact disc (CD) or digital versatile disc (DVD), floppy disk, magnetictape, or other memory components.

The memory 906 is defined herein as including both volatile andnonvolatile memory and data storage components. Volatile components arethose that do not retain data values upon loss of power. Nonvolatilecomponents are those that retain data upon a loss of power. Thus, thememory 906 may comprise, for example, random access memory (RAM),read-only memory (ROM), hard disk drives, solid-state drives, USB flashdrives, memory cards accessed via a memory card reader, floppy disksaccessed via an associated floppy disk drive, optical discs accessed viaan optical disc drive, magnetic tapes accessed via an appropriate tapedrive, and/or other memory components, or a combination of any two ormore of these memory components. In addition, the RAM may comprise, forexample, static random access memory (SRAM), dynamic random accessmemory (DRAM), or magnetic random access memory (MRAM) and other suchdevices. The ROM may comprise, for example, a programmable read-onlymemory (PROM), an erasable programmable read-only memory (EPROM), anelectrically erasable programmable read-only memory (EEPROM), or otherlike memory device.

Also, the processor 903 may represent multiple processors 903 and/ormultiple processor cores and the memory 906 may represent multiplememories 906 that operate in parallel processing circuits, respectively.In such a case, the local interface 909 may be an appropriate networkthat facilitates communication between any two of the multipleprocessors 903, between any processor 903 and any of the memories 906,or between any two of the memories 906, etc. The local interface 909 maycomprise additional systems designed to coordinate this communication,including, for example, performing load balancing. The processor 903 maybe of electrical or of some other available construction.

Although the software application 106 described herein may be embodiedin software or code executed by general purpose hardware as discussedabove, as an alternative the same may also be embodied in dedicatedhardware or a combination of software/general purpose hardware anddedicated hardware. If embodied in dedicated hardware, each can beimplemented as a circuit or state machine that employs any one of or acombination of a number of technologies. These technologies may include,but are not limited to, discrete logic circuits having logic gates forimplementing various logic functions upon an application of one or moredata signals, application specific integrated circuits (ASICs) havingappropriate logic gates, field-programmable gate arrays (FPGAs), orother components, etc. Such technologies are generally well known bythose skilled in the art and, consequently, are not described in detailherein.

The flowchart of FIG. 8 shows the functionality and operation of animplementation of the software application 106. If embodied in software,each box may represent a module, segment, or portion of code thatcomprises program instructions to implement the specified logicalfunction(s). The program instructions may be embodied in the form ofsource code that comprises human-readable statements written in aprogramming language or machine code that comprises numericalinstructions recognizable by a suitable execution system, such as aprocessor 903 in a computer system or other system. The machine code maybe converted from the source code, etc. If embodied in hardware, eachblock may represent a circuit or a number of interconnected circuits toimplement the specified logical function(s).

Although the flowchart of FIG. 8 shows a specific order of execution, itis understood that the order of execution may differ from that which isdepicted. For example, the order of execution of two or more boxes maybe scrambled relative to the order shown. Also, two or more boxes shownin succession in FIG. 8 may be executed concurrently or with partialconcurrence. Further, in some embodiments, one or more of the boxesshown in FIG. 8 may be skipped or omitted. In addition, any number ofcounters, state variables, warning semaphores, or messages might beadded to the logical flow described herein, for purposes of enhancedutility, accounting, performance measurement, or providingtroubleshooting aids, etc. It is understood that all such variations arewithin the scope of the present disclosure.

The software application 106 may also comprise software or code that canbe embodied in any non-transitory computer-readable medium for use by orin connection with an instruction execution system such as, for example,a processor 903 in a computer system or other system. In this sense, thelogic may comprise, for example, statements including instructions anddeclarations that can be fetched from the computer-readable medium andexecuted by the instruction execution system. In the context of thepresent disclosure, a “computer-readable medium” can be any medium thatcan contain, store, or maintain the logic or application describedherein for use by or in connection with the instruction executionsystem.

The computer-readable medium can comprise any one of many physical mediasuch as, for example, magnetic, optical, or semiconductor media. Morespecific examples of a suitable computer-readable medium would include,but are not limited to, magnetic tapes, magnetic floppy diskettes,magnetic hard drives, memory cards, solid-state drives, USB flashdrives, or optical discs. Also, the computer-readable medium may be arandom access memory (RAM) including, for example, static random accessmemory (SRAM) and dynamic random access memory (DRAM), or magneticrandom access memory (MRAM). In addition, the computer-readable mediummay be a read-only memory (ROM), a programmable read-only memory (PROM),an erasable programmable read-only memory (EPROM), an electricallyerasable programmable read-only memory (EEPROM), or other type of memorydevice.

Further, any logic or application described herein, including softwareapplication 106, may be implemented and structured in a variety of ways.For example, one or more applications described may be implemented asmodules or components of a single application. Further, one or moreapplications described herein may be executed in shared or separatecomputing devices or a combination thereof. For example, the softwareapplication described herein may execute in the same computing device900, or in multiple computing devices in the same computing system 100.Additionally, it is understood that terms such as “application,”“service,” “system,” “engine,” “module,” and so on may beinterchangeable and are not intended to be limiting.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

It should be emphasized that the above-described embodiments of thepresent disclosure are merely possible examples of implementations setforth for a clear understanding of the principles of the disclosure.Many variations and modifications may be made to the above-describedembodiment(s) without departing substantially from the spirit andprinciples of the disclosure. All such modifications and variations areintended to be included herein within the scope of this disclosure andprotected by the following claims.

What is claimed is:
 1. A method comprising: generating featuresignatures for pairs of records in a set of records, a given featuresignature representing common features between a pair of records;classifying the feature signatures; and generating a list of uniquefeature signatures and a set of sample record pairs for each uniquefeature signature.
 2. The method of claim 1, further comprisingselecting pairs of records that are likely to be related using ablocking operation.
 3. The method of claim 1, wherein the list furthercomprises a respective frequency that each unique feature signatureoccurs among the feature signatures.
 4. The method of claim 3, furthercomprising weighting each feature signature according to its respectivefrequency.
 5. The method of claim 1, further comprising obtaining userdata for determining one of a precision value or recall value of theclassifier.
 6. The method of claim 5, wherein the user data compriseslabels for the set of sample record pairs for each unique featuresignature.
 7. The method of claim 1, wherein further comprisingdetermining one or more exact matches between the features of the pairof records being compared to generate the pairs of records.
 8. Anon-transitory computer-readable storage medium for tangibly storingcomputer program instructions capable of being executed by a computerprocessor, the computer program instructions defining steps of:generating feature signatures for pairs of records in a set of records,a given feature signature representing common features between a pair ofrecords; classifying the feature signatures; and generating a list ofunique feature signatures and a set of sample record pairs for eachunique feature signature.
 9. The non-transitory computer-readablestorage medium of claim 8, the steps further comprising selecting pairsof records that are likely to be related using a blocking operation. 10.The non-transitory computer-readable storage medium of claim 8, whereinthe list further comprises a respective frequency that each uniquefeature signature occurs among the feature signatures.
 11. Thenon-transitory computer-readable storage medium of claim 10, the stepsfurther comprising weighting each feature signature according to itsrespective frequency.
 12. The non-transitory computer-readable storagemedium of claim 8, the steps further comprising obtaining user data fordetermining one of a precision value or recall value of the classifier.13. The non-transitory computer-readable storage medium of claim 12,wherein the user data comprises labels for the set of sample recordpairs for each unique feature signature.
 14. The non-transitorycomputer-readable storage medium of claim 8, the steps furthercomprising determining one or more exact matches between the features ofthe pair of records being compared to generate the pairs of records. 15.A device comprising: a processor configured to: generate featuresignatures for pairs of records in a set of records, a given featuresignature representing common features between a pair of records;classify the feature signatures; and generate a list of unique featuresignatures and a set of sample record pairs for each unique featuresignature.
 16. The device of claim 15, the processor further configuredselect pairs of records that are likely to be related using a blockingoperation.
 17. The device of claim 15, wherein the list furthercomprises a respective frequency that each unique feature signatureoccurs among the feature signatures.
 18. The device of claim 17, theprocessor further configured to weight each feature signature accordingto its respective frequency.
 19. The device of claim 15, the processorfurther configured to obtain user data for determining one of aprecision value or recall value of the classifier.
 20. The device ofclaim 15, the processor further configured to determine one or moreexact matches between the features of the pair of records being comparedto generate the pairs of records.